On Board Diagnostic (OBD) systems provide a method for vehicles to self-diagnose and report on the diagnosis through readers that are compatible with the OBD protocol. Early OBD systems often illuminated a light or switch to visual report an incident requiring attention or correction. In 1996, the OBD-II standard (an improvement over the original OBD) was mandated as being a required approach and capability for all automobiles sold within the United States.
The OBD-II standard provides for a specific diagnostic connector with pins of a particular orientation (i.e., a standard hardware interface), specific availability of certain electrical signaling protocols (i.e., communication protocols), and a particular messaging format (i.e., report out). FIG. 1 provides a representative view of a OBD-II diagnostic connector 100 and a tethered reader 150 with a display 175. In FIG. 1, the standard interface to be read from is typically a female 16-slot connector 100 (e.g., (2×8) J1962 connector) that provides a communication link from the vehicle (not shown) to a reader 150 having a corresponding male 16-pin connector 155 when the reader connector is attached to the connector. Once attached (the connector 100 and the reader connector 155) the reader 150 is capable to receive signal inputs from the vehicle through the connection 100 and visually present information about the vehicle on a screen 175 of the reader. Typically one of the slots 110 in the connector 100 provides power to the reader (i.e., scan tool or scan device) originating from the battery of the vehicle, although often separate power to the reader is provided for.
Some of the information about the vehicle that is available for display includes vehicle parameters and data from the engine control unit (ECU) and offers an information inside a vehicle, typically in an encoded format. Vehicle parameters that provide information about emissions, oxygen sensor status and conditions, cylinder operations, etc., are some examples. Many vehicle manufacturers have enabled the OBD-II Data Link Connector to be the primary connector in the vehicle through which many systems are diagnosed and programmed. Information concerning such systems is provided for as OBD-II Diagnostic Trouble Codes (DTCs) and are typically 4-digits with an alphabetic prefix of: P for engine and transmission (powertrain), B for body, C for chassis, and U for network. When properly connected and powered, the reader is able to decode the encoded vehicle data for the specific vehicle being evaluated and a diagnosis of vehicle systems and functions can be determined based on received codes.
OBD-II can interface with multiple communication protocols deployed inside a vehicle. There are five protocols used in the OBD-II vehicle diagnostics standard: (1) Society of Automotive Engineers (SAE) J1850 pulse-width modulation (PWM)—a standard of the Ford Motor Company; (2) SAE J1850 variable pulse width (VPW)—a standard of General Motors; (3) International Organization for Standardization (ISO) 9141-2, which is primarily used in Chrysler, European, and Asia vehicles; (4) ISO 14230 Keyword Protocol 2000 (KWP2000); and (5) ISO 15765 Controller Area Network (CAN) bus, where vehicles sold in the U.S. are required to implement CAN as one of their signaling protocols as of 2008.
OBD II has proven to be a standard having widespread utilization in the automobile industry and more recently in adjacent industrial and medical-related markets. However, the application of utilization of OBD II remains limited to localized methods of display and communications. For instance, the tethered communication arrangement of FIG. 1 proves to be inconvenient in accessing and storing the acquired data from the tethered reader. Other applications of OBD II are known to include the application of additional communication methods including universal serial bus (USB) communication linkages to local personal computers (PCs) adapted with the 16-pin connectors or Bluetooth® arrangements for nearby communications with PC devices (Bluetooth is a trademark of Bluetooth SIG, Inc.). Still others may involve the further implementation of customized protocols which provide to be uneconomical or unable to provide adequate flexibility in communications.
However, what is desired is the ability to extract vehicle diagnostics and related information from vehicles and equipment using one or more existing OBD II communications protocols while being able to link and store the acquired diagnostic and information in the cloud, via cloud computing, for further utilization.
As used herein the terms mobile device, third party system, smart phone, terminal, remote device, wireless asset, etc. are intended to be inclusive, interchangeable, and/or synonymous with one another and other similar communication-based equipment for purposes of the present invention though one will recognize that functionally each may have unique characteristics, functions and/or operations which may be specific to its individual capabilities and/or deployment.
As used herein the term cloud is intended to include a computing infrastructure that provides for entrusted services with data, software and computation over a network, where such a network is not constrained to be necessarily localized or of a particular configuration. The term cloud includes networks and network arrangements, such as the Internet, which provide for cloud computing capability.
As used herein the term cloud computing is understood to include methods of utilizing various connected computing devices, servers, clusters of servers, wired and/or wirelessly, which provide a networked infrastructure to deliver computing, processing and storage capacity as services where a user typically accesses cloud-based applications through a web browser, mobile application (i.e., app) or similar while the primary software and data are stored on servers of the cloud network at a remote location. Devices capable of providing computer processing capabilities (i.e, servers, PCs, computers, processors, etc.) are intended to be used interchangeably herein.